In industrial Ethernet and other real-time networking applications, latency for data transmission is an important issue. Minimizing the total latency is important. But perhaps even more important is minimizing any uncertainty in the latency. In Reduced Media Independent Interface™ (RMII™) based Ethernet systems, one problem is that transmit latency includes an uncertainty based on the relationship between the RMII™ reference clock and the transmit clock that is used to transmit the data on the physical medium.
The Reduced Media Independent Interface™ (RMII™) Specification (“RMII™ Specification”) published by the RMII Consortium sets forth an interface protocol for communications between Ethernet physical layer devices and application specific integrated circuit (ASIC) devices. The materials set forth in the RMII™ Specification are hereby incorporated herein by reference. Reduced Media Independent Interface™ is a trademark of the RMII Consortium. For clarity this patent document will not place the trademark designator TM on each reference to the initials RMII. It is understood that the initials RMII represent a trademark.
The RMII Specification defines an interface for transferring Ethernet packet data from a Media Access Controller or Switch to an Ethernet physical layer device. The RMII Specification describes the use of a fifty megahertz (50 MHz) reference clock to transfer data in two-bit increments. The two-bit increments are also referred to as “di-bit” increments.
The operation of a physical layer device is described in an IEEE publication entitled “IEEE Standards for Local and Metropolitan Area Networks: Media Access Control (MAC) Parameters, Physical Layer, Medium Attachment Units, and Repeater for 100 Mb/s Operation, Type 100BASE-T.” The short name of this standard is IEEE Standard 802.3. Within a physical layer device, as defined by the IEEE 802.3 specification, the one hundred megabit (100 Mb) data is transmitted as code-group data, which is a 4B5B encoding of four bit (“nibble”) data.
Due to the nature of the clock and data generation, there is no known relationship between the phase of the fifty megaHertz (50 MHz) reference clock that is used to initiate each nibble of data transfer and the phase of the one hundred twenty five megaHertz (125 MHz) transmit clock that samples that data for transmission to the Physical Layer. The lack of a known relationship between the phase of the two clocks results in a minimum twenty nanosecond (20 ns) uncertainty in the latency for transmitting the data as measured between the reference clock at the RMII and the actual transmission of the data on the physical medium. The twenty nanosecond (20 ns) time interval represents one clock period of the fifty megahertz (50 MHz) clock.
There is a need in the art for a system and method that is capable of minimizing the transmit latency uncertainty in 100 Mb RMII Ethernet physical layer devices. In particular, there is a need in the art for a system and method that can significantly reduce the transmit latency uncertainty from its present value of approximately twenty nanoseconds (20 ns).
In order to better understand the advance in the art that the present invention provides, a prior art system and method will first be described. FIG. 1 illustrates a system timing diagram for a prior art RMII System 100. FIG. 1 shows the basic components of a single transmit-to-receive Ethernet path from the Transmit Media Access Controller 110 (“Transmit Mac 110”) to the Receive Media Access Controller 120 (“Receive Mac 120”). Transmit Mac 100 sends the data to the Transmit physical layer device 130 (“Transmit Phy 130”). The Transmit Mac 110 sends a transmit enable signal (“TX_EN”) to the Transmit Phy 130 to enable the transmission of data. The data is sent over the link that is designated TXD[1:0] between the Transmit Mac 110 and the Transmit Phy 130.
The Transmit Phy 130 sends the data over a Category 5 cable 140 (“Cat5 Cable 140”). The data from the Cat5 Cable 140 is received by the Receive physical layer device 150 (“Receive Phy 150”). The Receive Phy 150 sends the data to the Receive Mac 120. The Receive Phy 150 sends a receive enable signal (“RX_DV”) to the Receive Mac 120 to enable the receipt of data. The data is sent over the link that is designated RXD[1:0] between the Receive Phy 150 and the Receive Mac 120.
A fifty megaHertz (50 MHz) first reference clock 160 (“REF_CLK1 160”) is coupled to the Transmit Mac 110 and to the Transmit Phy 130. A fifty megaHertz (50 MHz) second reference clock 170 (“REF_CLK2 170”) is coupled to the Receive Phy 150 and to the Receive Mac 120. The first reference clock 160 and the second reference clock 170 are each accurate to a precision of fifty parts per million (+/−50 ppm). The two reference clocks are independent.
RMII system latency is the delay from the Transmit Mac 110 to the Receive Mac 120 as measured at the RMII interface. Transmit RMII data is generated based on the first reference clock 160 (REF_CLK1 160). Receive RMII data is generated based on the second reference clock 170 (REF_CLK2 170).
The total transit time of the link from measurement at the Transmit RMII interface to the Receive RMII interface is given by the expression:tpTotalPhyRMII=tpPhyTxRMII+tpCable+tpPhyRxRMII 
The expression “tpTotalPhyRMII” represents the total transit time of the link. The expression “tpPhyTxRMII” represents the transit time through the Transmit Phy 130. The expression “tpCable” represents the transit time through the Cat5 Cable 140. The expression “tpPhyRxRMII” represents the transit time through the Receive Phy 150. The sum of these three expressions represents the RMII system latency.
We now consider just the RMII Transmit latency. The RMII Transmit latency may be measured from transmit data at the RMII interface to the first bit transmitted on the Cat5 Cable 140. It is understood that while Category 5 cable is the type most often used, other types of cable may be used to connect the Transmit Phy 130 and the Receive Phy 150.
To eliminate system dependencies at the RMII interface (i.e., transmit data setup to REF_CLK1 160), measurement is made from the rising edge of the REF_CLK1 160 clock signal that samples the transmit data. The measurement is made from the assertion of the transmit enable signal TX_EN to the first bit of JK on the cable. The code-group J and the code-group K are the first code-groups in a Start of Stream Delimiter (“SSD”).
Because the latency is consistent for all transmit data nibbles, measurements can be made from the Start of Frame Delimiter (“SFD”) or any other data in the data packet.
FIG. 2 illustrates how the “tpPhyTxRMII” transit time through the Transmit Phy 130 is measured. FIG. 2 illustrates a diagram showing the transmit delay in a prior art RMII transmit physical layer device. The first waveform 210 in FIG. 2 is the clock signal REF_CLK1 of the first reference clock 160. The second waveform 220 in FIG. 2 is the transmit enable signal TX_EN. The third waveform 230 in FIG. 2 is the data transmission signal TXD[1:0]. The fourth waveform 240 in FIG. 2 is the transmit delay (TD) waveform.
As shown in FIG. 2, the point in time from which the tpPhyTxRMII interval is measured is on the leading edge of the first REF_CLK1 pulse that samples the asserted transmit enable signal TX_EN. The end of the tpPhyTxRMII interval is located at the beginning of the code-group J on the transmit delay (TD) waveform. The tpPhyTxRMII interval is represented in FIG. 2 by an arrow that extends between a first vertical line that marks the beginning of the appropriate REF_CLK1 pulse and a second vertical line that marks the beginning of the code-group J. The tpPhyTxRMII interval represents the RMII Transmit latency.
The Phy Transmit process may be broken down into components. The Transmit Phy 130 processes data in the following stages. First, the data is subjected to an RMII to MII translation process that converts di-bits to nibbles. Second, the data then is processed in a 100BASE-X Physical Coding Sublayer (“PCS”) unit. Third, the data is then processed in a 100BASE-X Physical Medium Attachment (“PMA”) unit. Fourth, the data is then processed in a 100BASE-X Physical Medium Dependent (“PMD”) sublayer unit.
The latency uncertainty in the transmitter is contained in the RMII to MII translation process and in the Physical Coding Sublayer (“PCS”) unit. The implementations of the Physical Medium Attachment (“PMA”) unit and the Physical Medium Dependent (“PMD”) sublayer unit depend on the actual medium that is selected (e.g., copper cable or optical fiber) and are not significant to the determination of the transmit latency uncertainty. Therefore, only the RMII to MII translation and the operation of the Physical Coding Sublayer (“PCS”) unit are pertinent to the determination of the transmit latency uncertainty.
FIG. 3 illustrates a block diagram 300 of a prior art RMII to MII Translation unit 310 and a prior art Physical Coding Sublayer (“PCS”) unit 320. The inputs to the RMII to MII Translation unit 310 from the Transmit Mac 110 are the transmit enable signal TX_EN and the data signal TXD[1:0]. The RMII to MII Translation unit 310 also receives the REF_CLK1 signal from the first reference clock 160. Because the second reference clock 170 is not involved in the determination of the transmit latency uncertainty, the first reference clock signal REF_CLK1 will simply be referred to as the reference clock signal REF_CLK.
As shown in FIG. 3, the 50 MHz REF_CLK signal is provided to a Clock Multiplier unit 330. The Clock Multiplier unit 330 multiplies the clock signal REF_CLK signal to obtain a one hundred twenty five megaHertz (125 MHz) Transmit Clock signal. The Clock Multiplier unit 330 provides the 125 MHz Transmit Clock signal to both the RMII to MII Translation unit 310 and the Physical Coding Sublayer (“PCS”) unit 320.
The operation of the Physical Coding Sublayer (“PCS”) unit 320 will now be described. The PCS unit 320 comprises a 4B5B Encoder 340, a Serializer 350, a Transmit Bits State Machine 360, and a Transmit State Machine 370. The output of the PCS unit 320 is provided to a Physical Medium Attachment (“PMA”) unit (not shown in FIG. 3). The operation of the PCS unit 320 is described in Clause 24 of the IEEE 802.3 Specification.
The PCS unit 320 receives and encodes 4-bit (nibble) packet data in the 4B5B Encoder 340. The Transmit Bits State Machine 360 controls the operation of the 4B5B Encoder 340 and the Transmit State Machine 370. The 4B5B Encoder 340 provides the encoded data in the form of 5-bit code-groups to Serializer 350. Serializer 350 uses the 5-bit code-groups to create code_bit output and provides the code_bit output to the PMA unit (not shown in FIG. 3).
The PCS unit 320 receives the 4-bit (nibble) packet data on line mii_txd[3:0] from the RMII to MII Translation unit 310. The PCS unit 320 also receives an enable signal on line mii_tx_en from the RMII to MII Translation unit 310. The 4-bit (nibble) packet data is encoded in 4B5B Encoder 340 as a constant stream of 5-bit code-groups. The IEEE 802.3 Specification also defines an IDLE code-group as well as specific control code-groups to indicate Start of Packet, End of Packet, and error conditions. The packet encapsulation, using control code-groups, is shown in FIG. 24-5 of the IEEE 802.3 Specification. For convenience, FIG. 4 of this patent document sets forth FIG. 24-5 of the IEEE 802.3 Specification.
In sending a frame, the PCS unit 320 replaces the first byte of Preamble with a Start of Stream Delimiter (“SSD”) that consists of the two code-groups /J/ and /K/. At the end of the frame transmission, the PCS unit 320 appends an End of Stream Delimiter (“ESD”) that consists of the two code-groups /T/ and /R/ prior to resuming transmission of the IDLE code-groups /I/. Therefore an encapsulated packet will have the form /I/I/J/K/<data code-groups>/T/R/I/I/I/ where IDLE code-groups are sent continuously before and after the frame.
In all cases the IEEE 802.3 Specification defines transmit data to be sent as groups of five data bits including IDLE code-groups. The code-group requirements for transmit data are apparent in the Transmit state diagrams set forth and described in FIG. 24-7 and FIG. 24-8 of the IEEE 802.3 Specification.
One of the consequences of the definition as set forth in the IEEE 802.3 Specification is that the device must generate a constant 125 MHz Transmit Clock, and consistently transmit code-group data using the same phase of that 125 MHz Transmit Clock, as controlled by the Transmit Bits State Diagram (FIG. 24-7 of the IEEE 802.3 Specification). Therefore, the transmitter will consistently begin code-group transmissions on one of the five phases of the 125 MHz Transmit Clock. Because the transmit phase must be selected prior to the first packet transmission (because the IDLE code-groups must be sent for a long period prior to establishing a good link status), there is no fixed alignment of the 50 MHz reference clock to the 125 MHz Transmit Clock phase that is used to transmit the code-group data.
FIG. 5 illustrates the possible relationships between the 50 MHz reference clock and the phase of the 125 MHz Transmit Clock that generates the “sentCodeGroup.indicate” control signal as defined by the Transmit Bits state diagram. FIG. 5 is designed primarily to illustrate the relationships between the clocks and does not attempt to accurately model clock skews or overall data latency.
The first waveform 510 in FIG. 5 is the 50 MHz reference clock signal REF_CLK. The second waveform 520 in FIG. 5 is the 125 MHz Transmit Clock signal TX_CLK. The third through seventh waveforms (530 to 570) represent each of the five successive phases of the 125 MHz Transmit Clock.
For a given phase relationship (e.g., Phase 2) the delay from the reference clock REF_CLK positive edge to the “sentCodeGroup.indicate” signal varies by twenty nanoseconds (20 ns). As shown in FIG. 5, for data generated from the positive edge of the first pulse of REF_CLK (“Edge 1”), the delay to the next Phase 2 pulse is essentially one (1) Transmit Clock cycle or eight nanoseconds (8 ns). For data generated from the positive edge of the second pulse of REF_CLK (“Edge 2”), the delay to the next Phase 2 pulse is essentially three and one half (3.5) Transmit Clock cycles or twenty eight nanosecond (28 ns). Therefore, there is a twenty nanosecond (20 ns) difference in data latency that depends on the REF_CLK edge that is used to transfer the RMII data.
The minimum twenty nanoseconds (20 ns) uncertainty is dependent upon the device providing a consistent phase relationship between the reference clock signal REF_CLK and the “divide-by-five” circuit that creates the sentCodeGroup signal (such that only one of the phases is possible). If there is not a consistent relationship between the two functions, then any phase is possible and the uncertainty could be larger than twenty nanoseconds (20 ns). For example, Edge 1 to the next Phase 1 pulse is zero nanoseconds (0 ns) while Edge 2 to the next Phase 3 pulse is thirty six nanoseconds (36 ns).
As previously mentioned, there is a need in the art for a system and method that can significantly reduce the transmit latency uncertainty in 100 Mb RMII Ethernet physical layer devices from its current minimum value of approximately twenty nanoseconds (20 ns).
Before undertaking the Detailed Description of the Invention below, it may be advantageous to set forth definitions of certain words and phrases used throughout this patent document: the terms “include” and “comprise,” as well as derivatives thereof, mean inclusion without limitation; the term “or,” is inclusive, meaning and/or; the phrases “associated with” and “associated therewith,” as well as derivatives thereof, may mean to include, be included within, interconnect with, contain, be contained within, connect to or with, couple to or with, be communicable with, cooperate with, interleave, juxtapose, be proximate to, be bound to or with, have, have a property of, or the like.
The term “controller” means any device, system, or part thereof that controls at least one operation. A controller may be implemented in hardware, software, firmware, or combination thereof. It should be noted that the functionality associated with any particular controller may be centralized or distributed, whether locally or remotely.
Definitions for certain words and phrases are provided throughout this patent document, those of ordinary skill in the art should understand that in many, if not most instances, such definitions apply to prior uses, as well as to future uses, of such defined words and phrases.